[00:06.880 --> 00:14.440]  Hello and welcome to my talk here at the Aerospace Village at DEF CON SIGMODE.
[00:14.520 --> 00:20.300]  MITM, the mystery in the middle. My name is Matthew Gaffney and I'll be taking you through
[00:20.680 --> 00:30.120]  an introductory level talk about the Aircraft Information Systems Domain, also known as the AISD.
[00:31.240 --> 00:38.380]  We'll be covering through these topics throughout the 50 minutes or so talk today,
[00:39.060 --> 00:42.860]  covering most of it on EFBs, if I'm honest.
[00:43.720 --> 00:46.780]  So, why the mystery?
[00:47.480 --> 00:54.740]  So, the reason I call it the mystery in the middle was due to the lack of public information
[00:54.740 --> 01:01.500]  I could find about the AISD when I started my journey into aviation cybersecurity
[01:02.360 --> 01:08.240]  several years ago. I could find lots out about hacking avionics systems,
[01:08.240 --> 01:13.700]  IFE and all about their weaknesses, but very little about the AISD.
[01:14.300 --> 01:19.620]  So, that's the reason, the main reason for the talk today is to try and improve knowledge and
[01:19.620 --> 01:25.640]  awareness of this part of the aircraft and generate the healthy discussion about security
[01:26.060 --> 01:34.880]  within. So, logically, the AISD sits in between the Aircraft Control Domain and the Passenger
[01:34.880 --> 01:40.460]  Information and Entertainment Systems Domain, both known as the ACD and the PIESD.
[01:41.280 --> 01:47.400]  And essentially, what makes an aircraft, what's known as E-enabled.
[01:47.480 --> 01:54.100]  And E-enabled means that it will integrate, the aircraft will integrate with the airline
[01:54.100 --> 02:01.340]  IT systems to provide significant cost savings to the business. What it does is it allows remote
[02:01.340 --> 02:07.580]  maintenance and uploading of software updates, which is a key time saver, especially when you
[02:07.580 --> 02:14.540]  consider that previously, if you wanted to update the firmware on a module, you'd have to remove it,
[02:14.540 --> 02:17.760]  send it away, in the meantime, put in a replacement,
[02:18.540 --> 02:22.400]  then get the old unit back with the new firmware and swap it over.
[02:24.280 --> 02:32.440]  So, being able to upload new software remotely without having to remove modules or LRUs,
[02:33.560 --> 02:37.080]  is a considerable cost and time saving for an airline.
[02:38.320 --> 02:46.840]  It also allows the airline to download logs, both operational logs and security.
[02:47.440 --> 02:53.960]  So, for airlines, the AISD is the most important part to get right for the business. At least,
[02:53.960 --> 03:00.680]  that's my view of it. An airline cannot have much influence on how the ACD is constructed.
[03:00.680 --> 03:07.100]  Maybe a small amount of customization, but not very much at all. It's heavily regulated,
[03:07.100 --> 03:14.140]  it's heavily dependent on certifications, which are long, expensive and time consuming.
[03:14.520 --> 03:20.060]  So, the AISD is where the airline, the operator, really has to get it right.
[03:21.740 --> 03:27.680]  But there's lots of challenges in doing that. There's, across all aviation, not just
[03:27.680 --> 03:32.500]  enabled aircraft, there's a lot of older technology that gets reused.
[03:32.820 --> 03:39.400]  And it's not really a surprise, because if it works and it meets the requirements, why change
[03:39.400 --> 03:47.120]  it? Certifying new modules is expensive and time consuming as well. So, the older modules
[03:47.760 --> 03:53.140]  that are still fit for purpose will be reused a lot, because it's cheaper to modify them
[03:53.140 --> 04:01.420]  or to use the old ones. What this also means, though, is that when threats change over time,
[04:01.420 --> 04:07.040]  these older modules can be attacked in new ways nobody thought about when they were conceived.
[04:07.260 --> 04:15.760]  We're seeing this with avionics hardware today, but we are not really thinking about this when
[04:15.760 --> 04:23.120]  it comes to the AISD, and maybe we should. When I say we have new risks to manage, what I mean is,
[04:23.140 --> 04:31.140]  engineering now needs to consider cyber and infosec risks. Infosec teams now need to
[04:31.140 --> 04:36.020]  understand and consider engineering. Traditionally, these are two areas of the business that have
[04:36.020 --> 04:42.280]  been completely isolated. And it has allowed engineering to operate in its own little bubble,
[04:43.320 --> 04:52.440]  which has led to engineering not following infosec policy 100%. And you see examples of bad
[04:52.440 --> 04:57.640]  practice, such as post-it notes with passwords, or even passwords being written into procedure
[04:57.640 --> 05:02.820]  documentation, because it's easier to operate that way when you're an engineer than it is to
[05:02.820 --> 05:10.660]  use a password manager or to remember the password off by heart. At the same time, IT and infosec
[05:10.660 --> 05:15.440]  are implementing systems for engineers to use without fully understanding the constraints of
[05:15.440 --> 05:21.780]  engineering. They don't always have really good 3G connection on board an aircraft. They don't
[05:21.780 --> 05:31.340]  always have time to be able to learn new systems in depth. What they do have is very
[05:32.240 --> 05:39.840]  pressured time constraints in order to get aircraft back on the line, because all the time spent
[05:39.840 --> 05:49.620]  being fixed is money. But when IT comes along and comes along and implements a new IT system,
[05:49.620 --> 05:55.020]  say for example they don't have single sign-on, all of a sudden that engineer, instead of 20
[05:55.020 --> 05:59.340]  passwords to remember, they now have 21. And then we ask the question, why are they writing down
[05:59.340 --> 06:06.580]  passwords? So understanding the constraints and the difficulty of engineering can go a long way
[06:06.580 --> 06:14.050]  to improving the security posture of an airline. And operators really need to get these departments
[06:14.050 --> 06:21.070]  working together in harmony. When dealing with engineering and e-operations, you cannot bring
[06:21.070 --> 06:25.790]  the corporate information or cyber security mentality and templates to the party. They just
[06:25.790 --> 06:31.370]  won't work. You're dealing with an area of the business which historically has not been great
[06:31.370 --> 06:38.190]  with cyber. So you have to go slow. One thing that's on your side though, as an InfoSec person,
[06:38.190 --> 06:43.930]  is that aircraft engineers love processes and procedures. Oh boy, do they love it.
[06:44.750 --> 06:49.010]  Before you can even touch an aircraft on the ground, you must have a job card which outlines
[06:49.010 --> 06:57.830]  the steps engineers must take for each task. So if you can bring influence to these procedures
[06:57.830 --> 07:06.510]  to improve security, that's half the battle won. And then finally, I should probably explain that
[07:06.510 --> 07:11.790]  last comment on the slide. This is my humble opinion and I know many would disagree,
[07:12.270 --> 07:17.990]  but I feel that when looking at aviation security, hackers should not focus entirely on avionics.
[07:19.010 --> 07:25.450]  Although the ACV and the avionics have a number of well-documented and technical weaknesses,
[07:25.450 --> 07:33.310]  it does have a very effective physical security model. You can only access the avionics bay from
[07:33.310 --> 07:38.390]  outside the aircraft. So when the aircraft is in flight, not even the pilots can get to it.
[07:38.450 --> 07:44.610]  So only the engineers on the ground can do that. And if you're going to try to get access airside
[07:44.610 --> 07:50.330]  for legitimate reasons, you know how difficult it would be to get airside for illegitimate reasons.
[07:54.490 --> 08:01.870]  Also, there's usually only one network interface between the ACV and the AISD, and I'm talking
[08:01.870 --> 08:08.230]  about aircraft that are fully compliant with ARINC 821 here. But this separation is normally
[08:08.230 --> 08:15.150]  implemented with protections such as a firewall or even a data diode. And sometimes we also
[08:15.150 --> 08:23.090]  base that network communication on proprietary protocols, not on TCPIP. So if you can get into
[08:23.090 --> 08:27.610]  the ACV, yes, you can inflict a lot of damage, but gaining that access either through physical
[08:27.610 --> 08:34.710]  or technological means would be extremely difficult. And if you can go to that level,
[08:35.230 --> 08:41.030]  if you can get physical access to an aircraft, why go hacking? You know, you can do something
[08:41.030 --> 08:48.850]  much more nefarious with a much greater guarantee of success if that's what you wanted to do.
[08:49.830 --> 08:55.490]  So for me, instead, the aircraft information systems domain has multiple touch points ranging
[08:55.990 --> 09:03.810]  from the airline network, Wi-Fi, even the internet and the cabin. And these attack scenarios are much
[09:03.810 --> 09:08.970]  more traditional and realistic for hacking. Okay, it's not sexy. You can't control the
[09:11.290 --> 09:16.300]  aircraft control services from the AISD. You can have other effects on the aircraft,
[09:17.130 --> 09:22.250]  effects which may impact operations. And if you know what you were doing,
[09:22.250 --> 09:29.920]  you could modify some of the data presented to pilots. So
[09:33.000 --> 09:38.960]  manufacturer challenges. So I explained the challenge about technical debt. And the reason
[09:38.960 --> 09:50.700]  for that is that airworthiness timescales are huge. And they encourage, or they almost force
[09:52.100 --> 09:56.940]  manufacturers to really think about what they're going to reuse and what they have to rebuild from
[09:56.940 --> 10:02.120]  scratch. Because those brand new modules are really expensive to get certified.
[10:03.560 --> 10:11.000]  Challenges from the operator are very different and in many ways are quite significant.
[10:12.300 --> 10:19.020]  The key one is they have zero visibility of the manufacturer's risk assessment. So when
[10:19.020 --> 10:25.820]  the manufacturer is designing and building an aircraft, they perform extensive and detailed
[10:26.350 --> 10:29.610]  risk assessments to mitigate system vulnerabilities.
[10:32.180 --> 10:38.420]  They will mitigate many of these issues themselves, but they will also transfer some
[10:38.420 --> 10:46.020]  to the operators. And this is communicated in a number of ways, such as security handbooks or
[10:46.020 --> 10:52.720]  ANSOGs, depending on which manufacturer you're dealing with. But no operator will get to see
[10:52.720 --> 11:00.680]  details of the original vulnerability or the risk assessment. So despite the quality of this
[11:00.680 --> 11:06.500]  manufacturer guidance, these recommendations which come down, there's no real mechanism
[11:06.500 --> 11:13.340]  for the operator to assess the effectiveness of implemented controls. And this can,
[11:13.340 --> 11:18.540]  and from what I've seen, probably does lead to gaps in the cybersecurity protections
[11:18.540 --> 11:22.240]  of e-enabled aircraft at the operator level.
[11:24.340 --> 11:31.580]  When you think about it, airlines are heavily reliant on legacy IT systems. For example,
[11:31.580 --> 11:38.520]  many use at the core of their business, a TPF system, which handles all of the real-time
[11:38.520 --> 11:44.500]  transactions. It's not a traditional operating system. It is based on technology that was
[11:44.500 --> 11:54.360]  released in 1979. To program it, it's done in hexadecimal. It's just not what we would,
[11:54.360 --> 11:59.960]  people of my generation, would consider a traditional operating system. But it handles
[11:59.960 --> 12:06.740]  transaction messages one-to-one at an extremely high volume and extremely high speed.
[12:07.320 --> 12:12.180]  And what that does is make sure that the same seat isn't booked twice by separate transactions
[12:12.180 --> 12:17.940]  milliseconds apart. And there's nothing out there on the market that can really
[12:17.940 --> 12:27.620]  replicate that right now. Also, airlines, over time, have grown and have added new systems
[12:27.620 --> 12:34.900]  on top of the old systems. And until quite recently, this may have been done without
[12:34.900 --> 12:40.100]  consideration of all the risks. In fact, some of them would have been done before cybersecurity
[12:40.100 --> 12:49.140]  was really a thing. So some may not have followed good practice, such as network segregation.
[12:51.560 --> 12:56.780]  Airlines also operate 24-7. And that means that outages are very costly.
[12:58.200 --> 13:05.740]  When an airline IT system goes down, aircraft stop. They just cannot take off because they
[13:05.740 --> 13:09.360]  haven't got the information for the pre-flight.
[13:11.060 --> 13:16.020]  So any introduction of a new system that could have an impact on operations is
[13:19.200 --> 13:24.420]  risk managed to the nth degree. And there's a lot of risk avoidance going on when these new
[13:24.420 --> 13:30.300]  systems are put in place. Either that, or you just throw resources at it to make sure that
[13:30.300 --> 13:33.700]  if something does go wrong when you introduce a new system,
[13:33.700 --> 13:37.160]  that the impacts are mitigated as much as possible.
[13:38.700 --> 13:44.700]  What it does mean is that over time, airlines can become quite flat in their networks. And
[13:44.700 --> 13:49.580]  what that means is if the perimeter is at a breach, it's very easy for an attacker to then pivot
[13:50.540 --> 13:59.880]  inside the networks. So where regulators fit in. So speaking from a European perspective,
[14:00.760 --> 14:07.740]  there's some really positive steps going on right now in the critical national infrastructure
[14:07.740 --> 14:15.440]  sphere of which aviation forms a part. And maturity in cyber security, aviation cyber
[14:15.440 --> 14:21.320]  security is growing slowly and gathering momentum. Or at least it was before COVID.
[14:21.320 --> 14:28.360]  It was the last time I was really involved. From what I've seen, the UK CAA is growing the
[14:29.320 --> 14:34.920]  cyber oversight function in a very positive way. And rather than just setting out a framework
[14:34.920 --> 14:40.980]  and directing airlines to comply, they are working closely with operators instead,
[14:40.980 --> 14:45.980]  guiding them and helping them through their assure process, which is really good to see.
[14:45.980 --> 14:54.780]  So going back to this gap in the risk assessment, could the regulator help bridge that gap?
[14:55.340 --> 14:59.660]  The issue is sharing the risk assessments with operators as they are highly sensitive.
[15:00.460 --> 15:06.500]  Maybe some trusted government bodies could be given more details on the risks and help guide
[15:06.500 --> 15:11.540]  operators on the effectiveness of their controls without passing on that sensitive detail.
[15:12.460 --> 15:18.420]  If we can't trust the government, what about the aviation ISAC? Although they are a member
[15:18.420 --> 15:24.320]  organization, most of the large operators and manufacturers are members. Could this be another
[15:24.320 --> 15:31.420]  suitable mechanism to do the same thing? Whatever happens, I feel something does need to be done.
[15:31.420 --> 15:41.410]  Otherwise, pardon the pun, airlines could be flying blind. So here is a rather simplified
[15:41.410 --> 15:50.720]  overview of a E-enabled aircraft. This diagram is based on compliance to the ARIC-821 protocol.
[15:51.670 --> 15:55.500]  And as you can see, we've got the three main domains,
[15:55.500 --> 16:00.260]  the aircraft control domain, the aircraft information systems domain,
[16:00.260 --> 16:03.360]  and the passenger information and entertainment systems domain.
[16:04.720 --> 16:11.940]  The AISD, as well as being a main communications hub or hosting a main communications hub,
[16:11.940 --> 16:17.820]  will host the electronic flight bag if it's a class two. If it's a class two, the EFB will sit
[16:17.820 --> 16:24.560]  in the avionics. More on that later. Some aircraft have their flight standard panel, or FAP,
[16:24.560 --> 16:32.560]  connected in the AISD. And there's also occasionally printers, maintenance terminals,
[16:33.360 --> 16:39.680]  which can be USB or Ethernet port, depending on what kind of device you're using, if you're using
[16:39.680 --> 16:47.800]  just a straight up USB as a tool, or if you're using a portable data loader. And those maintenance
[16:47.800 --> 16:53.680]  ports are used as a backup for the IPSET panels that sit between the aircraft and the ground
[16:53.680 --> 17:04.520]  system. So these IPSET tunnels are really well... the security is excellent. So they are managed
[17:05.040 --> 17:10.840]  from mostly on board, but the ground systems are involved in the keying of the aircraft.
[17:11.560 --> 17:22.560]  And there's... I'll talk a bit more about PKI later on. What we do have is the EFBs,
[17:22.560 --> 17:29.540]  if they are connected to the AISD, they will often route traffic to the internet through
[17:29.540 --> 17:39.380]  the IPSET panel, through the DMZ and out into the internet, which is usually for software updates,
[17:39.380 --> 17:44.620]  and it's usually a very restricted set of websites where the EFBs can go.
[17:45.480 --> 17:49.600]  That is usually done on the ground as well, because if you imagine, if this is happening
[17:49.600 --> 17:54.800]  during the flight phase, you have the latency of the SATCOM connection down to the ground
[17:54.800 --> 18:03.940]  systems through the DMZ and out to the internet. So the response time on that in flight would be
[18:04.640 --> 18:13.380]  pretty long, but on the ground it's manageable. One thing to note as well is sometimes in
[18:13.380 --> 18:21.580]  enabled aircraft, instead of having a SATCOM in the AISD, there is an option whereby the
[18:21.580 --> 18:30.180]  manufacturer offers the operator the ability to use the passenger SATCOM connection. Remember,
[18:30.180 --> 18:35.280]  this SATCOM connection, the passenger name, does not go through this IPSET panel here,
[18:35.280 --> 18:39.540]  it goes off through the service provider's network.
[18:40.840 --> 18:48.240]  And one option that some manufacturers are offering to operators is that the
[18:50.180 --> 18:57.520]  information system domain here can connect to the ground systems, but through the same SATCOM here,
[18:57.520 --> 19:04.260]  and that is quite advantageous in terms of cost. The more you use SATCOM, the cheaper it is.
[19:04.260 --> 19:10.440]  So if you have two connections, that's going to cost you quite a bit of money. If you have one,
[19:10.440 --> 19:15.480]  yes, you're going to be paying for more data, but because prices come down with volume,
[19:15.480 --> 19:23.100]  you'll actually pay less overall. What I have seen though is quite promising that when this
[19:23.100 --> 19:31.000]  is implemented, the connection from the AISD into the SATCOM is through a separate VLAN.
[19:31.000 --> 19:37.000]  So essentially that's a mini network segregation on its own there, and that data is not accessible
[19:37.000 --> 19:46.010]  from the IFE or the cabin Wi-Fi. So moving on to my favorite subjects, electronic flight bags.
[19:46.630 --> 19:52.410]  So these have been a revolution for pilots. As the name suggests, they replaced the large and
[19:52.410 --> 20:00.670]  cumbersome and often heavy bags which were used by pilots to carry paper-based manuals.
[20:01.750 --> 20:09.910]  These bags would often weigh more than 25 kilos, and as well as being difficult to maneuver,
[20:09.910 --> 20:16.690]  they also contributed to physical injuries of pilots as well. Moving those bags around the cabin,
[20:16.690 --> 20:22.710]  around the cabin, around the cockpit, sometimes led to shoulder injuries because of their weight.
[20:24.690 --> 20:28.910]  Depending on the type of EFB, they can perform a variety of functions,
[20:28.910 --> 20:37.710]  including a documentation reference library. A type B can perform what's known as performance
[20:37.710 --> 20:44.170]  calculations. These give V1, VR, V2 speeds, all that kind of stuff. These are important for pilots
[20:44.170 --> 20:52.190]  to know. Enroute navigation, if you have a GNSS feed into the EFB. And if you have the relevant
[20:52.190 --> 20:58.070]  connections, access to NOTAMs, weather information, and the ability to do fuel calculations as well.
[20:58.990 --> 21:05.310]  Some operators also include bespoke applications that sit on the EFB, and these might be used to
[21:05.310 --> 21:12.430]  complement airline operation systems, so long as they reach the relevant approvals. But they will
[21:12.430 --> 21:21.350]  also help achieve the overall goal of EFBs, which is not just a reduction of paper inside the cockpit,
[21:21.350 --> 21:26.870]  but also faster access to information, which helps lower turnaround times and reduce workload
[21:26.870 --> 21:34.510]  in the cockpit. And non-pilots may not understand the importance of that last part.
[21:34.570 --> 21:40.810]  Many incidents of pilot error cite cockpit workload as either the main or as a contributing
[21:40.810 --> 21:47.970]  factor. So this makes EFBs not just an effective tool in reducing costs, but they also help you
[21:47.970 --> 21:56.090]  fly safely. Hardware categories have different names, depending on which regulator you sit under
[21:56.090 --> 22:03.430]  and how long you've been in the business. They're often used together, so I've included both here
[22:03.430 --> 22:10.650]  as some general characteristics. So a Class 1 or portable EFBs, they're often small devices
[22:11.510 --> 22:19.790]  and double up as corporate devices at the same time. Think of a small EFB, a small iPad with
[22:19.790 --> 22:25.170]  no connectivity to the aircraft. They're then considered like a paired personal electronic
[22:25.170 --> 22:33.370]  device and as such they must be stowed to take off, taxi and land. Class 2, these can be
[22:33.370 --> 22:42.630]  pilots or plane attached EFBs. These connect to the AISD with usually a one-way feed of data from
[22:42.630 --> 22:49.450]  the avionics. They can be integrated with the cockpit displays and their build is the responsibility
[22:49.450 --> 22:56.850]  of the operator. Quite often they are small laptops with operating systems such as Windows
[22:57.450 --> 23:02.510]  and then the manufacturer will provide the software which runs on top of that
[23:02.510 --> 23:10.150]  and connects the systems on board the AISD. It's worth mentioning that Class 2 EFBs have
[23:10.150 --> 23:15.710]  very different threat profiles depending on whether they are plane or pilot attached.
[23:16.630 --> 23:21.590]  So while plane attached EFBs are considered part of the minimum equipment list or NEL
[23:22.190 --> 23:27.350]  and tracked as an aircraft part, they're always under the control of the airline with coordinated
[23:27.350 --> 23:34.870]  and tracked movements between locations. Pilot attached EFBs are not. They enter and exit the
[23:34.870 --> 23:40.090]  cockpit when the pilot enters or leaves the aircraft. They are very likely to connect to
[23:40.090 --> 23:47.030]  all sorts of networks in hotels, cafes and airports so that the pilot can update software,
[23:47.030 --> 23:51.970]  navigation databases, notams, read corporate emails or even surf the internet.
[23:54.150 --> 24:02.510]  So you can see how the plane attached EFB has a very different threat matrix to that of a
[24:02.510 --> 24:07.490]  pilot attached one who may be anywhere in the world using insecure Wi-Fi.
[24:10.060 --> 24:18.760]  And then finally, I've included Class 3 for completeness because Class 3 don't really form
[24:18.760 --> 24:24.360]  part of the AISD, but they are an EFB. So they are integrated into the aircraft control domain
[24:24.920 --> 24:32.000]  and they have no connectivity outside of that. The build is the responsibility of the manufacturer,
[24:32.000 --> 24:35.480]  but it is maintained by the operator. And what I mean by that is
[24:35.480 --> 24:41.280]  that the hardware is fixed. The hardware cannot be changed. There may be software updates over
[24:41.280 --> 24:46.780]  time, but these are provided to the operator who then have the responsibility of maintaining
[24:46.780 --> 24:54.660]  the vibration. Class 3 EFBs are certified as part of the avionics. So the operator has next to no
[24:54.660 --> 24:59.640]  ability to make changes unless they wish to go through the trouble and expense of recertifying.
[24:59.640 --> 25:06.600]  And even though EFBs, Class 3 EFBs sit in the AISD, the ones I've seen are logically separated
[25:06.600 --> 25:11.480]  from the core avionics. And you have to interface through many different modules before you can
[25:11.480 --> 25:18.840]  bridge a gap between the control surfaces and the EFB. So attacking a Class 3 EFB to affect
[25:18.840 --> 25:23.120]  an aircraft in flight is still not that straightforward.
[25:25.340 --> 25:31.000]  Software categories. So Type A, really simple. They're just used for the storage and display
[25:31.000 --> 25:36.920]  of documents only. And like I said, these are typically Class 1. Class is PEDs and they get
[25:36.920 --> 25:44.720]  put away during the critical phases of flight. Type B applications, this is where it starts
[25:44.720 --> 25:53.100]  getting more fun. So like I said, they can perform performance calculations and they may actually
[25:53.100 --> 26:00.400]  access the internet on the ground and in flight. And they may be able to receive one-way data
[26:00.400 --> 26:05.540]  from the avionics. They are also the most common EFB software type I have seen.
[26:07.180 --> 26:14.620]  It's worth mentioning that Class 1 and Class 2 EFBs are built by the operator. And as such,
[26:14.620 --> 26:19.700]  they are not the responsibility of the manufacturer. Even though they may provide
[26:19.700 --> 26:25.480]  some or all of the software that runs on the device, it is up to the operator to ensure that
[26:25.480 --> 26:31.780]  they are working securely. For EFBs running Type B software, this is where things can get a bit
[26:31.780 --> 26:37.980]  blurred. According to regulations, any vulnerabilities in the software that could affect
[26:37.980 --> 26:44.100]  the operation of EFB software, regardless of who coded it, is the responsibility of the operator
[26:44.100 --> 26:50.860]  to mitigate. At the same time, details of any vulnerabilities do not seem to be passed on to
[26:50.860 --> 26:58.320]  the operator, just a series of recommendations for EFB security. Now these recommendations are
[26:58.320 --> 27:08.000]  really good, but as we'll come on to later, I don't feel they go far enough. Type C applications can affect
[27:08.000 --> 27:14.880]  the control of the aircraft in flight. So this is the really juicy part. Essentially, they can send
[27:14.880 --> 27:24.780]  data to the avionics. However, at the moment of going to press with this presentation, there are
[27:24.780 --> 27:31.180]  no current approvals that exist for Type C applications that I am aware of. I have seen
[27:31.180 --> 27:39.060]  future offerings from some manufacturers about having a bi-directional connection between the EFB
[27:39.060 --> 27:45.600]  and the flight management system which sits in the avionics. However, I have not enough detail there
[27:45.600 --> 27:56.590]  to give you the information about it. As I touched on on a previous slide, regulators provide operators
[27:56.590 --> 28:03.570]  with cyber security recommendations. Recommendations are also given by the manufacturers, but I feel
[28:03.570 --> 28:10.470]  that even when you combine these two sources, this advice does not go far enough. By that, I mean that
[28:10.470 --> 28:16.530]  there is a lack of detail in what to consider and measures to take. When it comes to regulatory
[28:16.530 --> 28:21.610]  documentation, security appears to be the poor cousin, with the majority of the document dedicated
[28:21.610 --> 28:29.050]  for physical characteristics and user interface design. The wording is also quite willowy and
[28:29.050 --> 28:33.850]  lacking in detail. It is certainly an area where I think there is a lot of room for improvement.
[28:36.840 --> 28:43.340]  Also, because implementing EFB security is the responsibility of the operator, some manufacturers
[28:43.880 --> 28:49.700]  appear to use this as a green light for poor implementations of technology, which on their own
[28:49.700 --> 28:56.800]  would be considered zero security by design. Instead, the security is designed to be assured
[28:56.800 --> 29:01.360]  by the inherent assumption that the operator's networks will never be compromised,
[29:01.360 --> 29:08.080]  or that malware will never find its way onto an EFB. Kind of like passing the security hot potato.
[29:10.080 --> 29:16.320]  At the same time, operators are not directly informed of any vulnerabilities, instead given
[29:16.480 --> 29:23.680]  a set of recommendations to implement. Unless the operator discovers any weaknesses, they would be
[29:23.680 --> 29:31.380]  unaware of the risks involved. And if they were aware of the risks, I'm more than certain that
[29:31.380 --> 29:42.630]  they would have targeted controls to them based on what they knew. Overall though,
[29:43.290 --> 29:50.870]  the recommendations given by some manufacturers are pretty good, although I feel there could be
[29:50.870 --> 29:56.910]  more detail in certain areas. I would like to share the document names and references with you.
[29:56.910 --> 30:03.250]  However, I am heavily constrained by NDA, as well as manufacturer efforts to protect IP. So I'm not
[30:03.250 --> 30:09.110]  allowed to give you these names, even though doing so would be for the benefit of any operators
[30:09.110 --> 30:18.960]  watching. And I cannot move on without briefly talking about class three or integrated EFBs.
[30:18.960 --> 30:25.740]  And even though they don't form part of the AISD, there are some use cases here which
[30:25.740 --> 30:32.900]  highlight a really important issue when it comes to technical debt.
[30:33.600 --> 30:38.600]  So like I said before, the hardware is fixed and the software updates come from the manufacturer.
[30:38.760 --> 30:45.360]  So to an operator, it may seem a very attractive prospect in terms of time and cost to get an EFB
[30:45.360 --> 30:53.000]  running. However, this category of EFB is not without its issues. And an example is an aircraft
[30:53.000 --> 31:00.820]  which I love, which is the Dreamliner. Having flown it many, many times, albeit not that long
[31:00.820 --> 31:06.220]  ago, I only started flying it about three years ago, I actually adore this aircraft. It is great
[31:06.220 --> 31:14.260]  to fly on as a passenger. But many Dreamliners have, especially the ones that first were
[31:15.360 --> 31:22.300]  brought to market, have Windows XP operating system integrated in the EFB which sits in the
[31:22.300 --> 31:28.920]  avionics. And this is a fact which gets a lot of surprise look from InterSec and IT professionals.
[31:29.480 --> 31:40.760]  But hang on. Remember, the 787 was designed in 2002-2003. Back then XP was king and would be for
[31:40.760 --> 31:46.960]  many years to come. The type approval and first flight for this aircraft was in 2009.
[31:47.880 --> 31:55.180]  Vista was available, but come on, Vista? Who would have changed? So when that aircraft was first
[31:55.180 --> 32:03.160]  went to market, it was delivered with EFP-EP4, developed using Windows XP.
[32:04.740 --> 32:11.380]  EP5 is available now, which uses Windows 10. However, not only do the upgrades come with a
[32:11.380 --> 32:18.180]  huge cost in terms of the units, but also a huge cost in terms of downtime and recertification of
[32:18.180 --> 32:25.990]  the avionics because it's a hardware change as well as a software change. So this kind of explains
[32:25.990 --> 32:35.630]  the issue of technical debt using more modern examples. Of course, we all think that an EFP
[32:35.630 --> 32:44.190]  on board a brand new modern state-of-the-art aircraft should be the most recent stable version
[32:44.190 --> 32:49.410]  of an operating system. But even in the timelines that we're talking about here, which are very
[32:49.410 --> 32:58.290]  small, we're seeing out-of-date operating systems being used in critical systems because of these
[32:58.290 --> 33:04.630]  timelines. And this issue is not limited to one manufacturer. I just brought up Boeing because of
[33:04.630 --> 33:12.750]  the knowledge I have of the BP-4, BP-5 versions and the operating systems. And it's not even
[33:12.750 --> 33:18.010]  limited to EFBs. It is all across the aircraft. I just wanted to discuss the technology trap. So
[33:18.010 --> 33:23.890]  those who may not fully understand why we see old tech in these brand new modern state-of-the-art
[33:23.890 --> 33:32.910]  aircraft. But it is interesting to think that the first Boeing 787s still have 20 years of life
[33:32.910 --> 33:40.810]  left in them or more. And when they come to end of life, will they still be running BP-4 with XP?
[33:40.810 --> 33:48.410]  I think some will. And we'll see. If Ken is still... Ken from Pentest Partners is still
[33:48.410 --> 33:55.290]  climbing around aircraft in breakers yards in 2040, then he may come across Windows XP
[33:55.290 --> 34:02.050]  inside the avionics, which will be a really, really cool thing to see him play with.
[34:03.830 --> 34:08.610]  But if you haven't seen their videos, they have some great walkthrough talkthroughs on 747s,
[34:08.610 --> 34:12.970]  which are going through the scrapyard today. And they also have older videos on their blog
[34:13.490 --> 34:21.330]  about dismantling old IFE systems a couple of years ago, which have 386 hardware inside them.
[34:21.370 --> 34:24.510]  And these are aircraft that were only dismantled a few years ago.
[34:26.210 --> 34:30.950]  So remember I said that in-air aircraft are flying data centers with half of it on the ground?
[34:30.950 --> 34:37.470]  Well, this is the other half. Ground systems. And they're used for keying and re-keying the PKI
[34:37.470 --> 34:43.670]  on the aircraft. They're used, like I said, for the key thing is the uploading of LSAPs and FLS
[34:44.160 --> 34:51.050]  to upgrade software modules on board the aircraft. A major, major time saver. But they also use for
[34:51.050 --> 34:58.330]  configuration changes, downloading of logs, and as a conduit for ESP connections. And this is done
[34:58.330 --> 35:05.190]  with some software provided by the manufacturer in a client-server relationship. The idea is that the
[35:05.190 --> 35:10.990]  operator would implement a Windows server, which runs the server software, and then the client
[35:10.990 --> 35:19.980]  would be installed on the engineer's laptop. The PKI on board the enabled aircraft is typically
[35:19.980 --> 35:25.800]  used to protect the VPN connection between the aircraft and the ground systems. It is also used
[35:25.800 --> 35:32.020]  to digitally sign the software that gets uploaded. So integrity checks can be done before it is
[35:32.020 --> 35:39.040]  installed in the aircraft. And this is one area that manufacturers seem to have gotten right with
[35:39.040 --> 35:43.280]  the latest enabled aircraft. At least the two main manufacturers in the world.
[35:44.300 --> 35:49.400]  While I do not have a PhD in cryptography, or anything higher than a BSc in any subject for
[35:49.400 --> 35:54.820]  that matter, the PKI implementations I have seen are simply excellent. And that shows the
[35:54.820 --> 36:03.890]  manufacturers are learning from previous issues. And that's great to see. As well as EFBs, I think
[36:03.890 --> 36:09.330]  ground systems require special consideration when it comes to security control implementation.
[36:11.010 --> 36:16.610]  The E-enabled aircraft being sold on the market today are truly excellent. Whether you're a pilot
[36:16.610 --> 36:21.290]  or a passenger, they are fantastic creations and a true credit to the teams involved in their
[36:21.290 --> 36:27.310]  development and manufacture. However, the same cannot be said of some of the supporting software.
[36:28.090 --> 36:33.090]  Some of the software distributed with modern aircraft is quite old, and they were likely
[36:33.090 --> 36:37.230]  coded at a time when there was very little consideration given to secure DevOps, or even
[36:37.870 --> 36:44.910]  cybersecurity at all. It seems that the approach back then was, so long as it works, it's fine.
[36:46.090 --> 36:54.770]  And that has led to some very insecure software being used with modern day aircraft.
[36:55.650 --> 37:00.970]  However, I'm seeing positive movements in this area. There are new versions of EFB and ground
[37:00.970 --> 37:05.950]  system software being developed today, which should be available in a few years' time,
[37:05.950 --> 37:10.990]  and that is going through what appears to be a sensible and secure approach to software development.
[37:11.350 --> 37:14.990]  So time will tell what comes out from that, but again, it's another positive move.
[37:17.720 --> 37:22.620]  As with EFB software, how many operators have looked at the ground system software
[37:23.620 --> 37:29.760]  from an attacker's perspective? Have they looked for weaknesses? Have they found any,
[37:29.760 --> 37:34.500]  and then combined this with the threat model and overlaid on the existing network architecture?
[37:34.940 --> 37:42.920]  Remember, like I said, a lot of airline networks have any, if at all, any segregation. So
[37:43.520 --> 37:49.140]  if the corporate network was compromised, could someone pivot into the ground systems and put
[37:49.140 --> 37:57.240]  your aircraft at risk? Also, conversely, could this software, at any weaknesses you identify,
[37:58.400 --> 38:05.020]  introduce new attack vectors or vulnerabilities in your systems, which could then be used
[38:05.020 --> 38:10.940]  to pivot into the corporate network? These are things that operators really need to consider and look at.
[38:12.520 --> 38:17.900]  Now, I have seen some manufacturers and third parties offer ground systems,
[38:18.180 --> 38:24.540]  a ground system service hosted in the cloud. And now, while I understand moving to the cloud is not
[38:24.540 --> 38:28.940]  the silver side of the bullet for any organization, although some seem to think it is,
[38:28.940 --> 38:34.300]  from my experience, these cloud solutions are normally put together very well from a security
[38:34.300 --> 38:41.440]  perspective. They also permit creative design in methods to mitigate weaknesses in the software.
[38:41.920 --> 38:48.380]  So, for example, if you had issues with the client software that would sit on the
[38:49.560 --> 38:56.020]  engineer's laptop, and you didn't want that interaction with the server going across the
[38:56.020 --> 39:02.600]  network, then what you could look at is putting both the server and the clients in separate
[39:02.600 --> 39:09.620]  lockdown enclaves inside a cloud solution, then implement a VDI to host the client's interface
[39:09.620 --> 39:16.200]  through a secure HTML5 web front end. And that gives you lots of opportunities to customize the
[39:16.200 --> 39:22.680]  security according to your threats and risks, and all sorts of other opportunities as well.
[39:22.980 --> 39:29.480]  So, these are certainly ideas that we're looking at, because the software that's available today
[39:29.480 --> 39:34.960]  doesn't seem to be that good, but some of the cloud's offerings are.
[39:38.540 --> 39:45.300]  Flight attendant panels. So, these are interesting from a cyber perspective. So,
[39:45.300 --> 39:51.520]  anyone that deals with industrial control systems will know that these are essentially
[39:51.520 --> 39:58.000]  what's known as a HMI, a human-machine interface. And these are used for lighting, air control,
[39:58.000 --> 40:03.760]  announcements, door status, lighting, emergency buttons, and they might also have bespoke
[40:03.760 --> 40:09.580]  features that the airline will implement. They can also be used for maintenance and
[40:10.860 --> 40:22.430]  for uploading FLS, LSAPs, and for downloading logs if the maintenance port is unavailable.
[40:24.110 --> 40:33.480]  So, why do FAPs have a security focus? Well, like any HMI, especially those ICS implementations,
[40:33.480 --> 40:38.340]  they're typically an easy target, especially those with a USB port.
[40:40.820 --> 40:46.500]  I did some research on FAPs, and while some are directly connected to both the AISD
[40:46.500 --> 40:51.220]  and the PIESD in e-enabled aircraft, there are none which have a connection
[40:52.140 --> 41:00.520]  to the ACD or avionics anymore. Not that I can see anyway. That said, I did raise concern
[41:00.520 --> 41:06.000]  about the possibility of a passenger inserting a USB stick loaded with malware
[41:06.600 --> 41:10.440]  into the FAP USB port, and what that would mean.
[41:12.160 --> 41:16.900]  So, the team I was in started asking the manufacturer some very probing questions,
[41:16.900 --> 41:21.520]  and to their credit, the manufacturer provided a highly detailed and impressive response,
[41:21.520 --> 41:26.740]  and it was actually done in person due to the sensitivity of the content. But what they showed
[41:26.740 --> 41:32.900]  us were that the technical controls to protect the ACD from the FAP were very robust. However,
[41:32.900 --> 41:38.380]  when asked the further questions, it seemed that the AISD was considered almost expendable
[41:38.380 --> 41:44.400]  in the malware onboard scenario. When asked about that, the response was that the AISD
[41:45.240 --> 41:50.780]  can be entirely functioning and it will not affect the airworthiness, which can be interpreted as
[41:50.780 --> 41:55.700]  the AISD can be riddled with malware, and the aircraft can still be operated legally.
[41:56.800 --> 42:03.780]  Fine, I thought. However, that got me thinking to the operational side, and I wondered how many
[42:03.780 --> 42:08.960]  pilots, knowing that an aircraft is infected with malware, yet still legal to fly, would actually
[42:08.960 --> 42:15.280]  fly it. What if, as an attacker, my goal was not to take control of the aircraft, but to affect
[42:15.280 --> 42:25.140]  the operations of an airline as a coordinated extortion or blackmail attack? Now, everyone in
[42:25.140 --> 42:35.320]  industry knows, regardless of the airline, that this USB port is off-limits, even to crew. Yet,
[42:35.320 --> 42:40.080]  I have spoken to Cabot crew from multiple airlines, and they have confirmed that they are told this
[42:40.080 --> 42:46.140]  in training. However, everyone in the industry also knows that this port is used extensively
[42:46.710 --> 42:51.800]  to charge crew devices, both official and personal, in spite of the rules.
[42:52.360 --> 42:57.480]  I have also seen passenger devices being charged in the FAP as the USB port in their seat wasn't
[42:57.480 --> 43:02.320]  working, and it was actually the crew who had done this as a courtesy to the passenger.
[43:03.660 --> 43:09.200]  So, what is clear from this is that, while people know there is a risk,
[43:09.200 --> 43:13.480]  it is clear the awareness training isn't working. Not all the time, anyway.
[43:16.620 --> 43:22.880]  I thought it important to also include some detail on some of the more general issues I have found,
[43:22.880 --> 43:29.760]  and I must state again, I am heavily bound by NDA, but I have reached out for advice
[43:29.760 --> 43:35.440]  and agreed parameters of what I can divulge here prior to this talk.
[43:37.160 --> 43:44.040]  So, one team I was in had been working on the security design of their ESDs,
[43:44.040 --> 43:48.900]  and we had planned project milestones to ensure that build documentation was accurate,
[43:48.900 --> 43:55.220]  and the device was built according to design. A lot of work had gone into locking the operating
[43:55.220 --> 44:00.840]  system down. It was Windows-based, and this is where I had a lot of extensive experience
[44:00.840 --> 44:06.460]  and knowledge. So, this is where I focused my attention. I knew that we had a pen tester who
[44:06.460 --> 44:10.420]  was going to look at it from the perspective of an ass hacker, and oversee my work,
[44:10.420 --> 44:15.500]  so I left the software alone. This is the manufacturer-provided software.
[44:16.060 --> 44:24.500]  I had naively assumed that this software would be fine, or at least not too bad.
[44:26.300 --> 44:31.220]  When it came to the pen test, I knew the build was solid, so I was surprised when on day two
[44:31.220 --> 44:38.560]  of the test, day two of the five-day test, Andrew, the pen tester, called. Now, anyone that deals with
[44:38.560 --> 44:43.620]  pen tests know that if they call you prior to the planned end date and it isn't a question,
[44:43.620 --> 44:50.760]  then it's bad juju. Andrew had not only found an API that was completely unprotected,
[44:50.760 --> 44:55.820]  there was no authentication, there was no encryption, but had written some code,
[44:55.820 --> 45:03.140]  but also written some code to exploit it. I was quite shocked, so I sent a message to the
[45:03.140 --> 45:08.140]  manufacturer straight away, and received a response that this was not a vulnerability,
[45:08.140 --> 45:17.970]  but in fact a feature. All I can say is that when I repeated this response to my colleagues,
[45:17.970 --> 45:24.330]  jaws across the room dropped to the floor. I took a step back and realized that in order to make
[45:24.330 --> 45:29.090]  the manufacturer understand, I had to do more analysis. Now, back when I was in the British
[45:29.090 --> 45:35.010]  army, I was taught to analyze attack scenarios by asking, so what, until you reach the answer.
[45:35.410 --> 45:39.150]  So I took the same approach with Andrew's code and turned the dial to 11.
[45:40.610 --> 45:43.830]  I found every single parameter I could.
[45:44.750 --> 45:51.270]  At the end, it would not have taken much to turn that resulting code into a very feasible malware
[45:51.270 --> 45:58.610]  for EFBs. I spoke with flight operations, pilots, and InfoSec, and demonstrated the rather trivial
[45:58.610 --> 46:09.500]  attack. Everyone I spoke to agreed that this was bad. So, despite this feedback, which included a
[46:09.500 --> 46:15.560]  dossier of potential outcomes which I had compiled from pilots and operations feedback,
[46:15.560 --> 46:20.860]  the only action taken by the manufacturer was to reduce the attack surface.
[46:21.920 --> 46:26.880]  They replied, in their opinion, the scenarios I had described were not feasible,
[46:26.880 --> 46:32.680]  and the whole vulnerability was dismissed. Now, it wasn't like I was proposing aliens would come
[46:32.680 --> 46:38.680]  down and attack planet Earth, although 2020 isn't over yet. One threat which they dismissed as
[46:38.680 --> 46:45.960]  unrealistic was the insider threat. Now, I found that really strange because this threat was on
[46:45.960 --> 46:50.580]  the operator's risk register, and I had been asked specifically to consider this threat
[46:50.580 --> 46:55.280]  when giving my updates to high-level security boards.
[46:58.440 --> 47:05.440]  Consequently, sometime later, however, I was informed that the software in question was
[47:05.440 --> 47:11.520]  going through a complete lifecycle upgrade, and that the project would include not just a secure
[47:11.520 --> 47:17.920]  DevOps approach, but security milestones with qualifiers as well. Now, I cannot take full credit
[47:17.920 --> 47:24.560]  for that change because I know that somebody had moved into a new role covering the security of
[47:24.560 --> 47:31.440]  such software, which means that they had already knew that there were issues, and that they were
[47:31.440 --> 47:39.020]  moving to close the gap when I had spoken about this issue with the API. And I know this person
[47:39.020 --> 47:42.640]  from my dealings with the manufacturer, and I'm very confident he will do good work.
[47:46.130 --> 47:50.570]  Further investigations I've made on other aircraft have uncovered examples of the same
[47:51.390 --> 47:58.690]  unprotected API. Different APIs, but unprotected all the same. And these are inside the AISD,
[47:59.750 --> 48:04.710]  so they are accessible from the EFB, they're accessible from other systems on board.
[48:05.490 --> 48:09.690]  And despite going through the responsible disclosure route as an independent researcher,
[48:09.690 --> 48:15.230]  I was not only dismissed for making unrealistic assumptions, but I had to fight for updates.
[48:16.330 --> 48:21.390]  Now, the assumption I made was based on a proposed commercial offering from the manufacturer,
[48:21.390 --> 48:25.410]  coupled with their own API documentation, detailing how it would work.
[48:26.990 --> 48:32.770]  Yet it was still considered unrealistic. Now, they may have made a separate assessment themselves,
[48:32.770 --> 48:38.230]  and started going down a different, more secure pathway for the release of this new functionality,
[48:38.230 --> 48:43.390]  which would be great. But I was not made privy to the details, so I have to say that for now,
[48:43.390 --> 48:47.910]  I don't know. If I do find out more, I will certainly update you.
[48:49.910 --> 48:55.190]  So hopefully that has given you a sufficient introduction into a network domain that is often
[48:55.190 --> 49:00.630]  overlooked by security researchers, but which has a lot of juicy issues that need to be addressed.
[49:01.030 --> 49:06.590]  Like I said, attacks on the avionics are really interesting, but getting access to them to
[49:06.590 --> 49:13.270]  exploit vulnerabilities is pretty difficult. While the AISD may not be as sexy or interesting
[49:13.270 --> 49:17.130]  on the surface, when you scratch a bit deeper, there's a lot to decipher.
[49:18.890 --> 49:22.410]  Touchpoints, while still quite difficult to exploit, are more accessible,
[49:23.050 --> 49:27.830]  considered more traditional to an attacker. And this means everyone from cabin crew,
[49:27.830 --> 49:32.270]  to engineers, flight ops, and infrasec, all have an important role to play
[49:32.270 --> 49:35.810]  in securing e-enabled aircraft at the operator level.
[49:38.430 --> 49:45.810]  Some advice I'd give to operators is, do not take the security of provided software for granted.
[49:46.250 --> 49:49.210]  Now, so I'm not talking about FLS and LSAPs here, what I'm talking about
[49:49.210 --> 49:55.770]  is the software that is provided to connect to your aircraft, so the EFBs, the ground systems, etc.
[49:57.150 --> 50:01.910]  Even the most modern aircraft today have some very basic vulnerabilities in the code.
[50:02.170 --> 50:07.550]  What is more worrying for me is that this software will achieve some kind of approval,
[50:07.550 --> 50:15.950]  in spite of these weaknesses. So don't assume because they have approvals that they are 100%
[50:15.950 --> 50:22.450]  secure. Make sure you perform some kind of assurance on software and systems, either
[50:22.450 --> 50:27.630]  using your internal teams, or if you don't have the skills in-house, hire an external
[50:28.190 --> 50:34.230]  expert or pen tester. It may be costly, but having an aircraft AOG for several weeks while you
[50:34.230 --> 50:41.070]  investigate a cyber attack, and have to replace all the onboard FLS or LSAPs, could probably cost
[50:41.070 --> 50:48.870]  you a lot more. Security in the operations is not the realm of one department alone.
[50:49.350 --> 50:53.690]  The multiple business areas that make up the operations require that InfoSec understand
[50:53.690 --> 50:59.790]  aviation and what cyber risks actually mean to aircraft. InfoSec also need to make sure
[50:59.790 --> 51:07.110]  that engineers and other business areas understand the risk context. It is a two-way street.
[51:07.610 --> 51:11.530]  I've seen that some operators have implemented a multi-discipline groupings,
[51:11.530 --> 51:17.130]  which handle these challenges. They're often called a cyber computer cell, which is a really
[51:17.130 --> 51:26.030]  cool name to have on your CV, just a little hint there. So these groupings often have at least
[51:26.030 --> 51:31.330]  one board member, and they combine knowledge and experience from multiple departments,
[51:31.330 --> 51:34.950]  and they ensure that issues are tackled in the best possible way for the business.
[51:35.210 --> 51:38.790]  From what I hear, they are extremely effective, and I would certainly recommend
[51:38.790 --> 51:42.610]  that you, if you don't have one already implemented in your business,
[51:42.610 --> 51:45.450]  and you operate a unit of aircraft, that you certainly look into it.
[51:46.910 --> 51:50.790]  And I suppose it finally goes without saying that you must involve your regulators as much as you
[51:50.790 --> 51:57.410]  can. They have access to the right people, the information, and the frameworks, with the right
[51:57.410 --> 52:03.090]  advice and the right guidance to guide you through difficult scenarios. So make sure you engage them
[52:03.090 --> 52:07.360]  as much as you can. And if you don't get satisfactory results from your regulators,
[52:08.870 --> 52:14.410]  sure, pop me a line. I can certainly help where I can. But finally, I'll sign off with a small
[52:14.410 --> 52:20.010]  piece of advice for operators. If you have someone in your organization who is as effective and
[52:20.010 --> 52:26.210]  competent an engineer as they are with InfoSec and cybersecurity, my advice would be to make
[52:26.210 --> 52:31.530]  sure that person never leaves your business. I'm not an engineer. I was lucky I had access to
[52:32.170 --> 52:40.290]  excellent engineers who were able to communicate to me exactly what the problems were,
[52:40.290 --> 52:47.410]  and to better understand systems so I could evaluate the risk. At the same time, these
[52:47.410 --> 52:53.090]  engineers were... they have a high level of intelligence engineers, so they could understand
[52:53.090 --> 52:57.250]  what I was telling them. And together we worked really well. But if you can incorporate that into
[52:57.250 --> 53:05.030]  one person, that's a very valuable asset indeed. So that's the end of your presentation. Hopefully
[53:05.030 --> 53:11.170]  that's enough information to whet your appetites in the AISD. There is a lot more there. I have to
[53:11.170 --> 53:17.410]  cram it into 50 minutes. So I will be available for questions in a session in the Discord channel
[53:17.410 --> 53:22.450]  from where you linked to this presentation. Please head over there and join in the discussion.
[53:22.750 --> 53:27.970]  Alternatively, you can grab me on Twitter or my website. There's an email link you can get on me.
[53:27.970 --> 53:31.610]  And I hope to speak to you all soon. Take care.
